-
Notifications
You must be signed in to change notification settings - Fork 14k
Fix the issue of unused assignment from MIR liveness checking #149072
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
| // If this place was dropped and has non-trivial drop, | ||
| // skip reporting field assignments. | ||
| if !is_direct && is_maybe_drop_guard { | ||
| continue; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is for avoiding report unused_assign for this line of code:
https://github.com/rust-lang/rust/blob/main/library/std/src/io/mod.rs#L393
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would there be an unused_assign for that line irrespective of whether there is a Drop impl?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there's no subsequent code that explicitly reads g.len, this assignment appears "unused".
I think the liveness checking in MIR only knows that the entire g will be dropped, but doesn't know the drop process will read g.len. The is_direct here is used to distinguish this case and avoid false positives for field assignments that Drop may use.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the past fields weren't checked, only whole variables, right? Why was that changed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The indirect statement is added here:
it seems to be trying to record the access for a variable with a field:
let mut waiter_queue = .... ;
...
waiter_queue.set_state_on_drop_to = ..@cjgillot correct me if I'm wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
another issue which related to Drop, but this PR does not fix it:
maybe we need a more general fix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder about a more principled fix. Instead of trying guess is this is a drop guard when emitting the diagnostic, should we change the dataflow analysis to make the Drop terminator mark live on interesting types? Maybe as a follow-up...
| IndexEntry::Occupied(mut o) => { | ||
| // There were already a sighting. Mark this statement as live if it | ||
| // was, to avoid false positives. | ||
| o.get_mut().live |= live.contains(index); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we update direct too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, I fixed it and added a test case.
57c1dcf to
4930d3e
Compare
b7c9e8d to
00f3155
Compare
Fixes #148960
Fixes #148418
r? @davidtwco
cc @cjgillot
My first try on MIR related code, so it may not be the best fix.